2.2 MML Definition
The MML language is very simple. It looks a
bit like an SGML application, but it's not.
The main concept of MML is the
part. Each part can be of a different type or use a
different charset. The way to delineate a part is with a
‘<#part
...>’ tag. Multipart parts can be
introduced with the ‘<#multipart ...>’ tag. Parts are
ended by the ‘<#/part>’ or
‘<#/multipart>’ tags. Parts
started with the ‘<#part
...>’ tags are also closed by the next
open tag.
There's also the ‘<#external
...>’ tag. These introduce
‘external/message-body’ parts.
Each tag can contain zero or more parameters on the form
‘parameter=value’. The values may be
enclosed in quotation marks, but that's not necessary unless the
value contains white space. So ‘filename=/home/user/#hello$^yes’ is
perfectly valid.
The following parameters have meaning in
MML; parameters that have no meaning are
ignored. The MML parameter names are the same
as the MIME parameter names; the things in the
parentheses say which header it will be used in.
- ‘type’
- The MIME type of the part
(
Content-Type).
- ‘filename’
- Use the contents of the file in the body of the part
(
Content-Disposition).
- ‘charset’
- The contents of the body of the part are to be encoded in
the character set specified (
Content-Type). See
Charset
Translation.
- ‘name’
- Might be used to suggest a file name if the part is to be
saved to a file (
Content-Type).
- ‘disposition’
- Valid values are ‘inline’ and
‘attachment’
(
Content-Disposition).
- ‘encoding’
- Valid values are ‘7bit’, ‘8bit’, ‘quoted-printable’ and
‘base64’
(
Content-Transfer-Encoding). See Charset
Translation.
- ‘description’
- A description of the part
(
Content-Description).
- ‘creation-date’
- RFC822 date when the part was created
(
Content-Disposition).
- ‘modification-date’
- RFC822 date when the part was modified
(
Content-Disposition).
- ‘read-date’
- RFC822 date when the part was read
(
Content-Disposition).
- ‘recipients’
- Who to encrypt/sign the part to. This field is used to
override any auto-detection based on the To/CC
headers.
- ‘sender’
- Identity used to sign the part. This field is used to
override the default key used.
- ‘size’
- The size (in octets) of the part
(
Content-Disposition).
- ‘sign’
- What technology to sign this MML part
with (
smime, pgp or
pgpmime)
- ‘encrypt’
- What technology to encrypt this MML part
with (
smime, pgp or
pgpmime)
Parameters for ‘text/plain’:
- ‘format’
- Formatting parameter for the text, valid values include
‘fixed’ (the
default) and ‘flowed’. Normally you do not specify
this manually, since it requires the textual body to be
formatted in a special way described in RFC 2646. See Flowed text.
Parameters for ‘application/octet-stream’:
- ‘type’
- Type of the part; informal—meant for human readers
(
Content-Type).
Parameters for ‘message/external-body’:
- ‘access-type’
- A word indicating the supported access mechanism by which
the file may be obtained. Values include
‘ftp’,
‘anon-ftp’,
‘tftp’,
‘localfile’,
and ‘mailserver’.
(
Content-Type.)
- ‘expiration’
- The RFC822 date after which the file may no longer be
fetched. (
Content-Type.)
- ‘size’
- The size (in octets) of the file.
(
Content-Type.)
- ‘permission’
- Valid values are ‘read’ and ‘read-write’
(
Content-Type).
Parameters for ‘sign=smime’:
- ‘keyfile’
- File containing key and certificate for signer.
Parameters for ‘encrypt=smime’:
- ‘certfile’
- File containing certificate for recipient.